IBIS Macromodel Task Group Meeting date: 14 January 2020 Members (asterisk for those attending): ANSYS: Dan Dvorscak * Curtis Clark Cadence Design Systems: * Ambrish Varma Ken Willis Kumar Keshavan Intel: * Michael Mirmak Keysight Technologies: * Fangyi Rao * Radek Biernacki Ming Yan * Todd Bermensolo Mentor, A Siemens Business: * Arpad Muranyi Micron Technology: * Randy Wolff * Justin Butterfield SiSoft (Mathworks): Walter Katz Mike LaBonte SPISim: * Wei-hsing Huang Teraspeed Labs: * Bob Ross The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - Arpad noted that we will have a meeting on the 21st of January. The meeting scheduled for the 28th is cancelled because of DesignCon. - Michael raised a discussion item about how AMI String parameters are handled. There were two questions. The first was related to if/how empty strings are handled. The second was a follow-on from Ambrish about the handling of double quotes. ------------- Review of ARs: - Walter to send the BCI for statistical proposal to Randy for submission to the Open Forum as a BIRD. - Done. BIRD201 was introduced at the last Open Forum meeting. - Fangyi to send the modified version of BIRD197 to Randy for submission to the Open Forum as BIRD197.7. - Done. BIRD197.7 was introduced at the last Open Forum meeting. - Walter and Randy to work on a new iteration of a proposal for BIRD198. - Randy reported he had some updated feedback to discuss before sending to the BIRD authors. -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the January 07 meeting. Randy moved to approve the minutes. Bob seconded the motion. There were no objections. ------------- New Discussion: BIRD198: Randy reviewed the syntax change suggestions and feedback that Randy, Walter, Arpad, Bob, and Mike L. had discussed. The feedback focused on the syntax examples the BIRD198 authors had provided. Randy noted that the group was fine with much of the proposal, but some proposed changes were: - The definition of the PDN requires two terminals, and the group agreed the terminals should be able to be defined by signal_name or bus_label. They propose a syntax to accomplish this. - The "_case" suffix isn't needed for the names of the C and R parameters. - The original example used lower case g for gig, but it must be G. - Suggesting the possibility of wrapping all the PDN domain sections inside a PDN domain begin/end keyword pair. Since the sections are all scoped under component, we either need a rule that they all have to be listed sequentially, or just define the being/end pair to wrap them all. - Suggesting that we leave it to the authors to explicitly define what the allowed parameter values and combinations are. - Suggest we allow NA to be used in min and max columns and specify that EDA tools use the typ value in such cases. - Suggest rules for allowable combinations of these values, e.g., is it allowable to not specify an R_leak? Specify what default values the EDA tools should use if a parameter is not defined. - Suggest a rule for the default model an EDA tool should use. If there are multiple PDN models under a PDN domain, the first one is the default. Bob noted that a typ value is required if a parameter is used in the model. He also noted that since these parameters could follow process-voltage-temperature conditions, not numerical min <= typ <= max, the ibischk parser would not be checking relative magnitudes of typ, min, max values. Arpad asked if we would draft a new revision of this BIRD based on the feedback or if that would be done by the original authors? Randy noted that he planned to encourage the authors to create a new BIRD198.1 after reviewing our feedback. Randy said that he would send out his proposed reply to the other members of the small group for a final review prior to responding to the authors. AMI String parameter questions: Michael reviewed an email he had sent to ATM the day before the meeting. The email quoted the definition of the AMI Type String. He provided an example with a String parameter with Format List in which the values were: ... (Type String) (List "Good" "Bad" "Indifferent" "") ... Michael noted that ibischk7.0.1 (as well as earlier versions) parsed this successfully, but he said that the "" empty string did not appear to be explicitly allowed by the specification. He noted that several Reserved parameters, e.g., Supporting_Files, and Model_Specific branch names explicitly prohibited empty strings as values. Michael noted that the null character 0x00 was not explicitly listed by the specification as one of the allowable ASCII characters, and he asked if it should be. Arpad noted that the null character is the C-style string termination character, but in the .ami file we have the parameter's value in double quotes and the end of the string is clear. Radek said we should not add any mention of the null character to the spec. He noted that the null character is a programming-side issue. We could decide to state that an empty string is allowed as a parameter value, but this has nothing to do with the null character. Michael said his primary concern was whether we should state that an empty string value is permitted. Arpad suggested we might state that a zero length string is allowed. Michael noted that we might need to say that it's allowed "unless otherwise prohibited", since there are already parameters that explicitly disallow empty string values. Bob noted that the "unless otherwise prohibited" statement might need to be strengthened, since there were other parameters, e.g., Repeater_Type, that had enumerated acceptable values, and the empty string would not be acceptable. He said tightening up the language and dealing with these cases could complicated any BIRD. Ambrish discussed the question he had posed in a reply to Michael's original email. Ambrish asked if the "" double quotes delimiting the String value in the .ami file should be passed to the model by the EDA tool. For example, should this: (filename "abc.txt") <-- including the "" or this: (filename abc.txt) <-- not including the "" be part of the ami_parameters_in string argument sent to the model? Arpad said he thought the "" characters just define the endpoints of the string value in the .ami file, and they should not be passed to the model. Ambrish agreed. Radek and Curtis disagreed and said the "" characters should be in the string passed to the model. Radek asked what happened if the filename in this example included spaces? Ambrish agreed the tool would probably have to pass the surrounding "" in that case. Curtis asked what would happen if the string value contained '(' and or ')', and noted that at a minimum this would make life more difficult for the model's parser if the surrounding "" weren't passed. Radek said the model should definitely be able to deal with it if the "" characters were passed to it. Ambrish said it was one thing for the model to handle the "" characters, but was it valid for the model to require that they be there? Radek said Michael's question about allowing empty strings provided a good example. If you're going to allow empty strings, what would you pass to the model in the empty string case if you don't pass the ""? Arpad asked if we would need a BIRD for this and who would volunteer to write it? Ambrish suggested discussion could continue via email. - Curtis: Motion to adjourn. - Ambrish: Second. - Arpad: Thank you all for joining. AR: Randy send the reply to the BIRD198 authors after final review by the small working group. ------------- Next meeting: 21 January 2020 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives